NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/dcom/modems-part1/4617

Internet Message Format | 1996-08-05 | 3.6 KB

Path: newsfeed.internetmci.com!xmission!xmission!not-for-mail
From: [e-mail] (Just Me)
Newsgroups: comp.sys.mac.comm,comp.dcom.modems
Subject: Re: faster than 28.8
Followup-To: comp.sys.mac.comm,comp.dcom.modems
Date: 8 Feb 1996 13:41:24 GMT
Organization: XMission Internet (801 539 0900)
Message-ID: <4fcui4$[e-mail]>
References: <[e-mail]> <4ds0fp$[e-mail]> <[e-mail]> <bgrubb-2301960739100001@10.0.2.15> <4e3lbi$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: xmission.xmission.com
X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]

Eric Shaw ([e-mail]) wrote:

: With PPP, this is possible, because PPP does its own compression in your
: computer before the data reaches the modem, so the modem has less data to
: compress.

    Wrong.  *Some* PPP implementations do BSD compression.  Most only
do VJ compression which only compresses the headers, not the actual data.
Anything that I have seen available in the US (i.e. commercial terminal
servers) does not do compression due to some copyright problem with the
compression code.  The BSD compression or LZW, possibly both?, is
"illegal" to implement in thte US.  There may be implementations out
there if they bought some type of license but it's unlikely in most
situations that both ends are supporting _full_ compression on a PPP
link, not just VJ header compression.

:
: The two Couriers were connected to two computers less than 10 feet apart
: from each other, and I connected the line jack on the two modems with a
: straight 8-foot phone cord, the same one that was used with the Supras
: achieving over 11K/s.  ATX3D was typed on one modem, then ATA on the
: other.  There was no significant line noise, as the data was not
: travelling through Southern Bell's phone lines.  The modems reported that
: they were connected at 33600bps due to the near perfect line conditions.
: Even with Ymodem-G, both computers reported transfer speeds between the
: Couriers of 6200-6300cps.
:
: It is interesting to note, however, that the Courier can achieve over
: 10K/s (but still not over 11K/s) when downloading from a NON-USR, but not
: when UPLOADING.  This agrees with the processor in it being too slow,
: because most compression protocols require more time to compress (like
: uploading) than to decompress (like downloading), probably including
: v.42bis.

    This just isn't true.  I have 2 Couriers and have done the same
test.  With Zmodem on compressable text (nothing extremely compressable,
just average output from 'ls -lR /', 2 meg worth) I see 11400 CPS.  This
is between 2 Courier Dual Standards (V.34) connected to the same 486/100,
thought the same generic $20.00 16550 UART I/O board, using the same
interrupt for both modems/ports even.  The OS is Linux.  As a side note, I
get the same results over _real_ phone lines that are far less than
perfect (when I dial from my first line back to my 2nd sometimes it's
28.8/28.8 sometimes 26.4 on one channel).
    What OS/hardware are you using?  Some OS's are very bad about
handling serial I/O, especially while multitasking, then add on top of
that the networking code that it's using (if it's an IP connection).
Also, don't the Mac's have some type of crippled serial port?  (something
to do with not being true full duples or only doing hardware flow control
for one direction of the data flow at a time).

--
[e-mail]